home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19980424-19980901 / 000416_news@newsmaster….columbia.edu _Wed Aug 26 10:19:32 1998.msg < prev    next >
Internet Message Format  |  1998-08-31  |  6KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id KAA15001
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Wed, 26 Aug 1998 10:19:31 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id KAA03002
  7.     for kermit.misc@watsun; Wed, 26 Aug 1998 10:19:31 -0400 (EDT)
  8. Path: news.columbia.edu!panix!howland.erols.net!news.idt.net!psinntp!pubxfer.news.psi.net!usenet    
  9. From: "Bob Kennedy" <bkennedy@peco-energy.com>
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: How I Implemented an application using C-Kermit fr VMS
  12. Date: Wed, 26 Aug 1998 10:13:20 -0400
  13. Organization: PSINet
  14. Lines: 89
  15. Message-ID: <6s156a$s0k$1@client3.news.psi.net>
  16. NNTP-Posting-Host: 159.214.60.222
  17. X-Newsreader: Microsoft Outlook Express 4.72.2106.4
  18. X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
  19. Xref: news.columbia.edu comp.protocols.kermit.misc:9142
  20.  
  21.  
  22. Plant Monitoring System
  23. System Health Monitor
  24.  
  25.  
  26. Written By:    Robert S. Kennedy
  27. Date:         August 14, 1998
  28.  
  29.  
  30.  
  31.    I work for a utility company, and one of my many functions here is to
  32. maintain a Plant Monitoring System (PMS).
  33.  
  34.    This PMS is a complex, redundant system.  It uses a high-speed,
  35. intelligent, distributed Data Acquisition System (DAS) to collect and
  36. produce plant data, and transmit this data to host processors.  The data is
  37. manipulated and validated by application programs, and then presented to
  38. operations personnel and other pertinent users on video terminals, plotters,
  39. and printers.  The key to configuring, controlling, and maintaining this
  40. complex configuration is knowledge of the hardware, peripheral components,
  41. applications, and the software design and implementation.
  42.  
  43.    The PMS runs on two VAX 4000-600 host computers per unit, on ethernet
  44. nodes.  There are 24 additional 4000-90a micro-vax workstations.  We use VMS
  45. ver. 6.1 on our 4 main hosts.  Because of the major complexity of this
  46. system, it can fail in many ways; Disk Drive space is usually at a premium;
  47. printer queues consistently fail, or stop; or the DAS shuts-down.  Any one
  48. of these failures is highly visible to the users of this system, therefore
  49. it is important to resolve  these failures in a timely manner.  In the past,
  50. we had a pager for which the operations department could call in the event
  51. of a computer emergency.  We would respond as quickly as we could to resolve
  52. the problem, but many times the effort was too late.  The need to respond
  53. more quickly or to look for emerging issues was becoming more and more at
  54. hand.
  55.  
  56.    After a brainstorming session with other individuals from my group, we
  57. came up with a solution.  This solution was that a DCL Command procedure
  58. could run once an hour and check various items in the system, like disk
  59. space, stopped queues, or if the DAS were down.  If there existed any
  60. problem on any hour, any one of the four host nodes could call us on our
  61. digital pager with some form of numeric code describing the problem.  That
  62. solution worked, and worked well, until we started adding more functions to
  63. this "System Health Checker".  The more we added, the more codes were
  64. needed, and pretty soon, we needed to carry around a "cheat sheet" with a
  65. description of all the codes.  What we needed was one of those new "fancy
  66. dancy" alphanumeric pagers, so the system could call us and tell us in
  67. "English", not numbers, what has gone wrong.
  68.  
  69.    While 'surfing' the Internet one day, when I happened upon a website,
  70. 'www.columbia.edu' and found a 'Kermit' page there.  I was familiar with the
  71. use of "Kermit" through our VAX/VMS systems, and started reading about the
  72. new release of "C-Kermit".  Being a programmer who knows how to read and
  73. program in "C", I became more curious.  I downloaded the newest version of
  74. "C-Kermit" for our VAX/VMS system and installed it, and found that it ran
  75. perfectly and without a hitch.  As I went on to read the miscellaneous
  76. documents, I found that this version of "C-Kermit" was not freeware, but
  77. shareware and that I should purchase the book as payment for the program.
  78. After receiving the book, I breezed through it and found a section on
  79. "Calling an Alphanumeric Pager".  This was just what the "doctor ordered".
  80. After talking to the people whom we use for our pagers, I was able to
  81. receive all the necessary documents on how to use their Telocator
  82. Alphanumeric Protocol (TAP).  Using, as a guide, the example macro in the
  83. C-Kermit book on "sending a one-line alpha page using TAP", I was able to
  84. send the alpha messages to our newly acquired on-call alpha pager.  Loaded
  85. with this new technology, I was able to apply this to our "Health Checker".
  86.  
  87.    Our "Health Checker" now performs approximately 17 separate functions on
  88. an hourly basis per host node.  The system monitors Disk Space; Queues; the
  89. DAS;  other systems attached to our PMS through a serial link; miscellaneous
  90. applications; as well as monitoring itself.  One of the four nodes is
  91. responsible for checking the other three to see if the "Health Checker" is
  92. running in the "SYS$BATCH" queue or not.  Each of these separate sub-modules
  93. has the ability to call the alpha pager with a message describing the
  94. problem.  This is done by a system-wide logical pointing to a DCL command
  95. procedure, that basically runs "C-Kermit" with script code using the TAP.
  96. Once an hour all four nodes check their respective functions, and twice a
  97. day, the system will page us with a message that each of these four nodes is
  98. "AOK".
  99.  
  100.    C-Kermit opened up the door for us to perform this proactive search for
  101. problems and a means by which to contact us in the event of an emergency
  102. with a well-defined "English" message.  This is most effective around 03:30
  103. in the morning when the system calls to tell us that DAS is down, or any
  104. other type of problem.  If we were still using that "Digital pager", we
  105. would need to find, then lookup the code describing the problem.  This, for
  106. most of us, is difficult at three in the morning.